[FEATURE] Add support for X509v3 extensions for authentication #5701
Conversation
Signed-off-by: Lamine Idjeraoui <[email protected]>
laminelam
requested review from
DarshitChanpura,
RyanL1997,
cwperks,
derek-ho,
nibix,
peternied,
reta,
shikharj05 and
willyborankin
as code owners
|
@laminelam FYI I synced your feature branch with main since there was a breaking change fix that needed to be merged tof fix the failing tests: #5698 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5701 +/- ##
==========================================
- Coverage 72.94% 72.91% -0.03%
==========================================
Files 420 420
Lines 26269 26351 +82
Branches 3974 3987 +13
==========================================
+ Hits 19162 19215 +53
- Misses 5187 5201 +14
- Partials 1920 1935 +15
🚀 New features to boost your workflow:
|
| return new AuthCredentials(username, roles).markComplete(); | ||
| } catch (InvalidNameException e) { | ||
| log.error("Client cert had no properly formed DN"); | ||
| log.debug("Client cert had no properly formed DN (was: {})", principal); |
There was a problem hiding this comment.
nit: this would be repetitive with logs at debug level. Considering only logging the DN with this log line. i.e. log.debug("DN (was: {})", principal);
There was a problem hiding this comment.
Thank you for this PR @laminelam ! The changes lgtm. I just had one minor comment. Please make sure to raise a PR to the documentation-website repo to document how the username and role attribute can be configured for client cert auth.
|
@reta, maybe you could give a second review, thanks! |
| Pattern pattern = null; | ||
| if (!Strings.isNullOrEmpty(regex)) { | ||
| try { | ||
| pattern = Pattern.compile(regex, Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE); |
There was a problem hiding this comment.
I believe (at least per RFC [1]) that the pattern dialect being used is not compatible with Java pattern spec: like * is equivalent of Java's .* , or I am missing something here? thank you
There was a problem hiding this comment.
Right now I treat the value as a Java regex and it should clearly be stated in the documentation.
As for the RFC, the wildcard spec is only for the case of SAN:DNS hostnames (e.g., *.example.com glob). We can still support both regex and glob but I'am afraid this would make things more complex and creates confusion for the user. I see three options:
A) Keep regex only and document clearly.
B) For DNS, support RFC-6125 glob by default with an explicit regex: opt-in.
C) Allow both for all SAN types via small prefixes (?glob) / (?regex) with auto-detect for simple globs.
What are your thoughts?
There was a problem hiding this comment.
We can still support bother regex and glob but I'am afraid this would make things more complex and creates confusion for the user. I see three options:
Certainly don't intent to complicate things, basically my question would be - when if ever the pattern will be (and should be) Java compatible? (yes, we could document etc, but from practical standpoint). This looks to me as restriction that is artificial (due to the fact we use Java standard library), may be we could completely disregards the pattern handing?
There was a problem hiding this comment.
The reason of using java regex is that we need to support groups capturing. Why? Because we want to be able to extract specific information to use it as a username or back-end role. For example, let's say the cert passes such info in the following format:
roles_attribute:SAN:URN:googleservice/groupid/123/dept
We want our regex to not only much this format but also extract the group id =123 and use in roles.
To be honest I was very hesitant to add regex support, the first version of this PR didn't have it. So I am willing to remove it for now and restrict the validation to exact much, and may in a futur PR extend it to support regex.
There was a problem hiding this comment.
To be honest I was very hesitant to add regex support, the first version of this PR didn't have it. So I am willing to remove it for now and restrict the validation to exact much, and may in a futur PR extend it to support regex.
Certainly +1 to that, thank you @laminelam
4 participants
Resolves #5643 & #4209
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.